DF behaviour: Allow zero-horizon windows/views #13
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
nmnobre
added
enhancement
|
The solution proposed here is, nevertheless, less than ideal. The compiler should produce code to prevent the creation of zero-horizon views altogether in the first place. |
…appending of view
Richard549
approved these changes
Jul 1, 2020
There was a problem hiding this comment.
The tracing state transitions are fine, if there are no dependences to resolve then we can avoid swapping in/out of the dependency-resolution state.
(After looking at it, I have also included the code that appends the view to the chain in the state, and included it in the PR.)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This aims at supporting zero-horizon windows in OpenStream programs. The behaviour should be semantically equivalent to not referencing the respective stream at all in the task creation statement.
@a-pop commit 46ab217 removes an assertion in
wstream_df_resolve_n_dependences(). This allows my programs to run but it will obviously cause problems. In particular, I can no longer use thepeekclause, instead having to resort to a zero-burstinput.@a-pop There is an odd zero-decrease call to
tdecrease_n()after I modifiedwstream_df_resolve_dependences()and__built_in_wstream_df_prepare_dataso I added a guard totdecrease_n(). Is this okay? There's probably a better fix once we know the reason for that call.@Richard549 This bypasses trace state changes on both
tdecrease_n()andwstream_df_resolve_dependences()on early exists, can you please check if this is okay?